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Remarks 

Applicants corrected typographical errors and made further clarifying statements 
in connection with certain mathematical equations provided in the specification. No new 
matter was added. 

In the Office Action dated August 23, 2005, the Examiner rejected claims 1-20 
under 35 U.S.C. 112, first paragraph, as failing to comply with the enablement requirement. 
Applicants submit that the specification and drawings enable one skilled in the art to make 
and/or use the invention. 

With regard to claims 1 and 11, Figure 1 graphically compares Applicants' 
Active Design Process Management (ADPM) transition model to conventional Design Process 
Management approaches, (p. 8, 11. 18 - 26). The implementation of next-state functions, 6, 
in conventional approaches feature a design process manager (DPM) component, (p. 8, 11. 19 - 
20), which, in practice, connects a user with conventional CAD tools, (p. 8, 11. 20-22). In 
comparison, Applicants provide a "novel design process manager system that applies 
operations requested by designers . . . [and] generates any necessary constraints and 
incorporates them in the design state," (p. 8, 11. 6-9), and a design constraint manager (DCM) 
and notification manager (NM) in the implementation of next-state functions, 6. (p. 8, 11. 23 - 
24). 

The specification provides a detailed description, (p. 8,1.4-p. 11,1. 17). As 
an example of the level of detail provided by the specification, Applicants cite the passage: 
"Constraint information is consolidated into data that explicitly supports heuristics as described 
below, and the design state is properly labeled with this data." (p. 9, 11. 8 - 10). The "data" 
referred to is described in detail, for example, in the discussion of "Heuristics Based on 
Feasible Subspaces," (p. 10, 11. 13 - 23), "Heuristics Based on Number of Constraints," (p. 
10, 1. 24 - p. 11, 1. 5), and "Heuristics Based on Constraint Violations," (p. 11, 11. 6 - 17): 
thus,/^), fi h and are "data." 
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The specification provides an example of an implemented embodiment, (p. 8, 
1. 18 - p. 14, 1. 5). Specifically, "a prototype was built to demonstrate the new capabilities of 
this invention." (p. 11, 11. 19 - 20). "These capabilities are illustrated by means of 
screenshots for an example collaborate design process," (p. 11,1. 19-21; Figures 2-4), and 
"the constraint-based heuristic support of the invention was implemented in the Minerva III 
design process manager," (p. 11, 11. 25 - 26). 

One skilled in the art would recognize that each block of Figure 1 , for example, 
could be implemented as a software module connected to a database that maintains the 
information. In such a configuration, the design process manager (DPM) could manage 
information on the status of a design project, its different components, who is working on 
them, its goals, and which variables each designer is working on for a particular component, 
for example the width of a transistor in a circuit, (p. 8, 11. 5 - 7; p. 11, 1. 18 - p. 14, 1. 5), and 
the design constraint manager (DCM) could manage information about constraints between the 
variables, (p. 8, 11. 9 - 10). Thus, for example, when a design is divided into several parts, 
constraints between the parts can be generated, (p. 8, 11. 7 - 10; p. 8, 1. 24 - p. 9, 1. 11), and 
information that supports constraint-based heuristics can be consolidated, (p. 8, 11. 11 - 12; p. 
9, 11. 8 - 10; p. 9, 1. 27 - p. 11, 1. 17). 

A constraint, for example, is a relation that needs to be maintained for a design 
to be correct. A constraint can be evaluated by several means including via a software tool, 
by examining a list of acceptable values (e.g. , if the value is not on the list, the constraint is 
violated), or through equations (e.g., a + b = c). The DCM could store information related 
to the aforementioned means. The equations provided in the specification are an illustration 
of this concept. 

In view of the typographical corrections made to the specification, all variables 
associated with the relations provided in the specification are defined. Moreover, a 
methodology for implementing these relations is readily apparent to one of ordinary skill in the 
art: Applicants provided not only a written description of the heuristics supported by their 
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ADPM, but provided mathematical equations that can be directly translated into, for instance, 
software code. Furthermore, Applicants provided a detailed description, with associated 
Figures, of the "prototype . . . built to demonstrate the new capabilities of this invention." 
(p. 11, 1. 18 - p. 14, 1. 5). In this description, an application of, for example, relation (3), (p. 
13, 11. 7 - 17), and relation (2), (p. 12, 11. 16 - 24), are provided. As yet another example, 
with regard to relation (3), (p. 11,1. 17), consider again the constraint equation a+b = c and 
an additional constraint equation a = 2d; consider also that a = b = c = d= 1. For a given 
design variable, e.g., "a," relation (3) takes into account the number of constraints in which 
"a" appears and then takes into account which of those constraints are violated. In this 
example, "a" appears in both constraints and both constraints are violated, hence a x = 2. 
Claims 1 and 11 comply with 35 U.S.C. 112, first paragraph. 

Claims 2 - 9 and 12 - 20 depend from claims 1 and 1 1 respectively. For at least 
the reasons claims 1 and 1 1 comply with 35 U.S.C. 1 12, first paragraph, claims 2 - 9 and 12 - 
20 comply with 35 U.S.C. 112, first paragraph. 

In the Office Action dated August 23, 2005, the Examiner rejected claims 1-20 
under 35 U.S.C. 1 12, second paragraph, as being indefinite for failing to particularly point out 
and distinctly claim the subject matter which Applicants regard as the invention. 

With regard to claims 1 and 11, conflicts are not known in advance of the 
constraints: a conflict is a violation of a constraint. First, constraints between the variables are 
identified, generated automatically, and stored. For example, it is identified that for a design 
to be correct, a + b = c. Then once one or more of these variables achieve a value, it can be 
evaluated whether the constraint is violated. Therefore, conflict information is not known in 
advance of evaluating the network design constraints to obtain conflict information in response 
to the signals. Claims 1 and 11 comply with 35 U.S.C. 112, second paragraph. 



S/N: 10/050,773 

Reply to Office Action of August 23, 2005 



AttyDktNo. UOM 0246 PUS 



Claims 2 - 9 and 12-20 depend from claims 1 and 1 1 respectively. For at least 
the reasons claims 1 and 11 comply with 35 U.S. C. 112, second paragraph, claims 2 - 9 and 
12 - 20 comply with 35 U.S.C. 112, second paragraph. 

In the Office Action dated August 23, 2005, the Examiner rejected claims 1-20 
under 35 U.S.C. 102(b) as being anticipated by Narain (U.S. Patent No. 6,651,228). 

Narain discloses a special-purpose system to find functional defects in a 
hardware design, (c. 4, 11. 30 - 45). Consistent with other known systems, Narain assures 
correct design by simply checking that a flow of logical signals is correct, (c. 4, 11. 18 - 21). 
Examiner has made no prima facie showing that Narain discloses each and every element of 
claims 1 and 11 respectively. For example, with regard to claim 1, Narain, at least, does not 
disclose generating a network of design constraints which represent interactions among the 
variables of the design, evaluating the network of design constraints to obtain conflict 
information in response to the signals, or transmitting signals to designers affected by the 
conflict information to provide constraint-based guidance to the affected designers in the 
collaborative design environment. For example, with regard to claim 1 1 , Narain, at least, does 
not disclose a design process manager for generating a network of design constraints which 
represent interactions among the variables of the design, a constraint manager for evaluating 
the network of design constraints to obtain conflict information in response to the signals, or 
a notification manager for transmitting signals to designers affected by the conflict information 
to provide constraint-based guidance to the affected designers in the collaborative design 
environment. Claims 1 and 11 are not anticipated under 35 U.S.C. 102(b) by Narain. 

Claims 2 - 9 and 12 - 20 depend from claims 1 and 11 respectively. Because 
Examiner has made no prima facie showing that Narain discloses each and every element of 
claims 1 and 1 1 respectively, Examiner has made no prima facie showing that Narain discloses 
each and every element of claims 2-9 and 12 - 20 respectively. Claims 2-9 and 12 - 20 are 
not anticipated under 35 U.S.C. 102(b) by Narain. Claims 2 - 9 and 12 - 20 provide additional 
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limitations over claims 1 and 1 1 respectively and are therefore further not anticipated under 
35 U.S.C. 102(b) by Narain. 



The claims are in a condition for allowance. Applicants request a notice to that 



effect. Applicants also invite a telephone conference if the Examiner believes that it will 
advance the prosecution of this application. 



Please charge any additional fees or credit any overpayment as a result of the 



filing of this paper to our Deposit Account No. 02-3978. A duplicate of this paper is 
enclosed for that purpose. 
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Southfield, MI 48075-1238 
Phone: 248-358-4400 
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